…odule

Sentry-Dynamic.xcframework contains a framework named `Sentry.framework`
inside, so `@import Sentry;` needs `-framework Sentry`. CocoaPods
derives the `-framework` flag from the xcframework's own filename, so
with `Sentry-Dynamic.xcframework` it generates `-framework Sentry-Dynamic`
and RNSentry fails to compile with `Module 'Sentry' not found`.

Switch to `Sentry.xcframework` (the static product) — enclosing name
matches the framework name inside, so CocoaPods generates the correct
`-framework Sentry` and the module resolves. Static also means no embed
step, so no chance of the archive-signature collision either.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- Sentinel-check `Sentry.xcframework/Info.plist` instead of directory
  existence so an interrupted `unzip` doesn't leave a partial tree that
  short-circuits future re-downloads (cursor-bot low).
- `rm_rf(target_dir)` before extracting so a stale partial tree from an
  earlier failure doesn't survive the next attempt.
- Verify `Info.plist` after extraction so a release with a changed
  archive layout fails fast with a clear message instead of silently
  succeeding and later confusing `pod install` (sentry-bot medium).
- Honor `SENTRY_USE_SPM=0` as a deprecated alias for the CocoaPods
  fallback so CI/local envs still exporting the old draft variable
  don't silently opt into the new xcframework path (cursor-bot medium).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…ramework

Even with `s.vendored_frameworks = 'ios/Vendor/Sentry.xcframework'`,
CocoaPods didn't propagate a framework search path into RNSentry's own
compile phase, so `#import <Sentry/SentryDefines.h>` failed with
"file not found". Set `FRAMEWORK_SEARCH_PATHS` explicitly via
`pod_target_xcconfig` so the pod can resolve the `Sentry` framework
module from the vendored xcframework's parent directory.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

`s.pod_target_xcconfig` is setter-only in the CocoaPods version used by
RN 0.86, so calling `s.pod_target_xcconfig.merge!(…)` crashed pod install
with `undefined method 'pod_target_xcconfig' for Pod::Specification`.

Accumulate the settings into a local hash across the conditional branches
and assign to `s.pod_target_xcconfig` once at the end. Same fix applied
to the pre-existing new-arch/RN<0.71 branch (which had the same latent
bug).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Assigning `s.pod_target_xcconfig` at the end of the podspec (after
`install_modules_dependencies`) clobbered every setting RN's helper had
written, so the RN-provided HEADER_SEARCH_PATHS were dropped and every
`#import <Sentry/…>` (as well as any other framework header lookup) failed
during RNSentry's compile phase.

Assign the base `pod_target_xcconfig` (with DEFINES_MODULE and the
Sentry FRAMEWORK_SEARCH_PATHS) BEFORE `install_modules_dependencies` so
it merges its RN settings on top rather than the other way around. For
the RN < 0.71 branch — where `install_modules_dependencies` doesn't
exist — the local hash is mutated after that assignment, so re-assign
inside that branch.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…H_PATHS

Confirmed by local repro: Xcode's `-F <dir>` does NOT descend into an
`.xcframework` bundle at search-path lookup time. Given
`FRAMEWORK_SEARCH_PATHS = ".../ios/Vendor"`, Xcode only sees
`Sentry.xcframework` as an opaque directory and never finds
`Sentry.framework` inside — so `#import <Sentry/SentryDefines.h>`
fails with `Module 'Sentry' not found`.

Instead of a single parent-of-xcframework path, enumerate every slice
directory inside the extracted xcframework (via `Dir.children` — no plist
gem needed) and register each as a framework search path. Xcode then
picks the matching slice based on the target platform/arch. The list is
computed at pod-install time, so future sentry-cocoa releases can add
new slices without a code change.

Apply the same paths to `s.user_target_xcconfig` so the host app target
(any user code writing `#import <Sentry/…>` directly) also resolves the
module.

Verified locally: RNSentry pod and the sample app both compile — only
the RN bundle script (unrelated to Sentry) blocks the local build.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Two problems with the previous flat-slice-list approach:

1. Xcode's Swift module precompiler walked slices that don't match the
   current build target (e.g. watchos-* on an iOS build) and errored
   with 'unsupported Swift architecture'. Fix: split slices by target
   SDK and emit conditional FRAMEWORK_SEARCH_PATHS[sdk=...*] entries
   so each SDK build only sees the slices it can actually consume.

2. PODS_TARGET_SRCROOT is defined in a pod's own xcconfig but not in
   the aggregate/user-target xcconfig. Using it in user_target_xcconfig
   made the app-target search paths resolve to nothing, so app code
   writing @import Sentry failed with 'Module Sentry not found'. Use
   PODS_ROOT/../.. for the user-target xcconfig - from the app's Pods
   dir that's the RN app root where node_modules/@sentry/react-native/
   lives.

Slice-to-SDK mapping is computed at pod-install time from the extracted
xcframework so future sentry-cocoa releases pick up new slices
automatically.

Verified locally: sample's SentryNativeInitializer.m now resolves
@import Sentry.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Two follow-up fixes for the vendored xcframework path:

1. RNSentryCocoaTester (in packages/core/RNSentryCocoaTester/) had its
   test target fail with 'Sentry/Sentry.h' file not found because its
   Podfile layout is different from the RN sample apps — the previous
   ${PODS_ROOT}/../.. path assumed a RN app root with node_modules,
   which doesn't apply here. Switch user_target_xcconfig to the
   absolute path known at pod-install time (via File.expand_path on
   the podspec dir). Absolute paths are baked into Pods xcconfigs on
   every install, so shareability across machines isn't a concern —
   Pods/ is regenerated per install anyway. This also removes the need
   for a separate 'pod_target' vs 'user_target' path.

2. Build RN 0.86.0 legacy hermes ios production dynamic (use_frameworks!
   :linkage => :dynamic mode) failed with:
     Undefined symbols: __swift_FORCE_LOAD_$_swiftCompatibility56
   Sentry.xcframework contains Swift code, but RNSentry.podspec's
   source_files was Objective-C++ only, so Xcode never auto-linked
   the Swift runtime compatibility libraries required by the static
   Swift symbols embedded in Sentry.xcframework. Add an empty
   RNSentrySwiftLinkStub.swift and include `.swift` in source_files
   glob so Xcode treats RNSentry as Swift-consuming and pulls in the
   compat libs.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Adding a Swift file to RNSentry.podspec's source_files (to force Xcode
to link Swift runtime compat libs when consuming Sentry.xcframework)
made CocoaPods treat RNSentry as a 'Swift pod'. On RN < 0.75,
React-hermes doesn't define modular headers, so pod install fails:
  The Swift pod `RNSentry` depends upon `React-hermes`, which does
  not define modules.

The Swift compat lib linkage is only needed when linking
Sentry.xcframework's static Swift symbols into a dynamic framework
(use_frameworks! :dynamic), which is a RN 0.86+ scenario anyway. Gate
the .swift file on RN >= 0.75 to preserve pod install on the older
matrix cells.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- Move the SPM/xcframework entry out of the already-released `## 8.17.0`
  section into a new `## Unreleased` section (danger check). The merge
  from main pulled 8.17.0's release notes on top and swept the entry
  inside them.

- Add a private constant to RNSentrySwiftLinkStub.swift. A pure-comment
  Swift file compiles to nothing, which would defeat the whole reason
  for the stub (forcing Xcode to link Swift runtime compatibility libs
  when consuming Sentry.xcframework's static Swift symbols).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- sentry_utils.rb: replace system('curl',…) with URI.open from stdlib
  open-uri. Same net behavior, no shell escaping to worry about, pure Ruby.

- sentry_utils.rb + RNSentry.podspec: drop the runtime slice-enumeration
  helpers. Sentry.xcframework's layout has been stable across releases,
  so hardcode the slice → SDK map into a frozen constant
  (SENTRY_XCFRAMEWORK_SLICES_BY_SDK) and iterate it directly in the
  podspec. Less code, no filesystem scan on every pod install. If
  sentry-cocoa ever ships a new platform slice, add a line to the
  constant.

- scripts/update-cocoa.sh: extend set-version to also refresh the
  Sentry.xcframework.zip SHA256 checksum in sentry_utils.rb. Before
  this, bumping sentry-cocoa required editing the checksum by hand — a
  silent recipe for typos that would break every user's pod install
  with a checksum-mismatch error. Now the script downloads the new
  archive, computes SHA256, and rewrites both the version key and the
  Sentry value in place with a sanity-check.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Repro on a bare RN app installed via `pnpm install
--config.node-linker=isolated` (pnpm's strict store makes package
directories read-only): pod install failed with

    Permission denied @ dir_s_mkdir - .../node_modules/.pnpm/
    @sentry+react-native.../ios/Vendor

Under pnpm's isolated store (and Yarn PnP), the SDK package directory
is either a read-only symlink into a shared store or not materialized
on disk at all — writing our xcframework cache there is not portable.
Move the cache to `~/Library/Caches/sentry-react-native/xcframeworks/
<version>/` (macOS user cache, always writable, deduped across
projects on the same machine). Override with `SENTRY_XCFRAMEWORK_CACHE_DIR`
for CI or enterprise setups.

Also drop `s.vendored_frameworks = 'ios/Vendor/Sentry.xcframework'`.
It was decorative — CocoaPods doesn't stage vendored xcframeworks for
`path:` (development) pods, which is why we already had to wire
FRAMEWORK_SEARCH_PATHS manually. Linking still happens: clang's
`-fmodules-autolink` (default) emits the `-framework Sentry`
directive as soon as `@import Sentry;` in RNSentry.mm resolves the
module through the search paths. With the vendored_frameworks entry
gone, the podspec no longer points at a path that only existed inside
node_modules.

Verified locally against a bare RN 0.86 sample installed via pnpm
strict + chmod a-w on the package's ios/ directory: pod install
succeeds, build succeeds, app boots, native crash → dSYM upload path
still works.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>